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INTRODUCTION 

A  movement  has  begun  in  the  software  engineering  industry 
towards  the  development  of  tools  which  allow  system  designers  to 
observe  the  logical  flow  of  their  system  designs  before  implementation 
begins.  Designers  using  such  tools  may  see  exactly  how  a  system  will 
behave  at  the  earliest  stages  of  development.  Such  tools  will  be  used 
to  demonstrate  the  completeness,  or  lack  thereof,  of  system 
requirements  specifications.  These  specifications  are  stored  in  a 
"requirements  structure",  a  formal  format  completely  describing  both 
the  data  flow  and  control  flow,  and  the  internal  functional 
descriptions  of  the  functional  components  of  systems. 

As  specifications  for  a  system  are  developed,  they  are  added  to 
the  "requirements  structures"  for  the  system.  Later,  the  "requirements 
specifications"  may  be  executed  by  these  tools  in  a  manner  similarly 
used  by  interpreters.  In  effect,  the  system  may  be  "taken  for  a  spin" 
to  determine  how  it  behaves.  If  properly  designed,  these  tools  can  be 
used  for  structured  walk-throughs  of  the  completed  system.  In  fact,  an 
environment  utilizing  these  tools  and  a  structured  design  methodology 
could  improve  productivity  and  system  reliability  by  ten-fold. 

At  Virginia  Tech  research  on  such  an  environment  is  already 
underway.  The  environment  is  called  the  Dialogue  Management  System. 
This  paper  presents  a  design  for  the  tools  and  environment  described 
above  as  used  in  the  Dialogue  Management  System. 

The  Dialogue  Management  System  (DMS)  is  being  developed  to 
improve  human-computer  dialogues.  It  consists  of  three  major 
components:  a  dialogue  development  facility,  a  computational 
development  facility,  and  a  structured  development  methodology 
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[JOHND82a].  The  Behavioral  Demonstrator  (BD)  is  perhaps  the  most 
important  tool  included  in  DMS.  The  BD  aids  in  the  functional 
decomposition  and  verification  of  an  application  system.  Users  of  the 
BD  may  execute  requirements  specifications  for  an  application  system 
even  when  the  system  is  at  the  most  abstract  level  of  development.  In 
one  respect,  the  BD  can  be  viewed  as  a  development  environment 
supporting  the  other  tools  in  DMS  in  a  manner  consistent  with  the 
structured-development  methodology  presented  in  [YUNTT82],  This  report 
presents  a  basic  design  for  implementation  of  the  BD  and  concludes 
with  a  description  of  a  sample  application- system. 


1.0  THE  BEHAVIORAL  DEMONSTRATOR 

A  formal  language  for  describing  the  "requirements  structure" 
for  application  systems  is  basic  in  the  design  of  any  Behavioral 
Demonstrator  (BD).  In  that  formal  language  three  ingredients  are 
needed: 

1.  A  means  for  describing  functional  components  of  systems  in 
terms  of  modules,  sets,  or  entities. 

2.  A  means  for  describing  the  requirements  specifications  and 
data  flow  between  the  functional  components. 

3.  A  group  of  control  structures  describing  the  flow  of  control 
between  the  functional  components. 

Languages  exhibiting  these  features  can  be  high-level  procedural 
languages,  menu-driven  interpreters,  or  even  graphical  languages  such 
as  the  Supervised  Flow  Diagram  Language  chosen  for  use  in  DMS. 


The  Supervised  Flow  Diagram  Language  is  presented  [ YUNTT83 ]  as 
a  high-level  requirements  specification  language  supporting  the 
Supervisor-Based  System-Development  Methodology  (SBSDM).  The  SBSDM 
was  created  to  improve  software  design  and  productivity  by  human¬ 
factoring  human- computer  dialogues.  In  this  methodology,  human- 
computer  dialogues  are  constructed  separately  from  the  system's 
computational  components  [JOHND82b].  Application  programme~s  construct 
computational  components;  whereas,  "dialogue  authors"  d  ign  human- 
factored  human-computer  dialogues  [J0HND82a].  SBSDM  is  thf  structured- 
development  methodology  for  which  DMS  is  being  developed. 

During  requirements  specification.  Supervised  Flow  Diagrams 
(SFDs)  are  constructed  using  an  SFD  editor.  Once  created,  the 
graphical  nodes  in  the  SFDs  may  be  executed  by  the  BD  to  verify  that 
system  requirements  are  being  met.  The  BD  allows  a  user  to  walk 
through  a  system  at  its  most  abstract  level  of  development  and 
determine  how  a  system  behaves.  In  this  way,  the  BD  may  be  viewed  as 
both  a  requirements  "verifier"  and  a  system  behavioral  demonstrator. 
As  each  worker  node  in  the  SFDs  is  expanded  (i.e.  written  by  either  an 
application  programmer  or  a  dialogue  author),  the  Behavioral 
Translator,  a  tool  similar  to  the  BD,  may  be  used  to  execute  the 
finished  module.  Hence,  a  user  can  use  the  BD  as  a  structured  walk¬ 
through  supervisor  during  all  phases  of  system  development.  After  all 
primitive  modules  have  been  expanded  in  an  SFD,  another  BD-like  tool 
compiles  the  SFD  "program",  generating  the  finished  system.  Viewed 
this  way,  the  BD  may  be  used  as  a  development  framework  supporting  the 
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1.1  The  SFD  Language 

At  its  most  abstract  form  of  development,  a  system  will  consist 
of  little  more  than  supervisory-cells  structured  in  a  hierarchical 
representation  consistent  with  the  SBSDM.  Figure  1.1.1  illustrates 
this  hierarchical  representation  and  the  corresponding  SFD  structures. 

SYSTEM  REPRESENTATION: 

STRUCTURE  OR  SUPERVISORY  CELLS 


SUPERVISORY  STRUCTURE  3nd  SUPERVISORY  CELLS 
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Wherein  each  supervisory-cell  defines  "what"  is  to  be  done  in  a 
given  function,  the  corresponding  expansion  of  a  supervisor-cell 
defines  "how"  the  function  is  to  be  performed  [ YUNTT83 ] .  This 
expansion  is  known  as  the  supervised  flow  diagram  corresponding  to  its 
supervisory-cell.  As  depicted  in  Figure  1.1.1,  it  is  quite  possible 
for  nodes  in  an  SFD  to  be  supervisory-cells  for  other  SFD's. 
Consequently,  each  supervisory-cell  may  have  two  types  of  subfunctions 
in  its  SFD  expansion:  supervisory-functions  and  worker-functions. 
Where  the  expansion  of  a  supervisory- function  is  a  corresponding  SFD, 
the  expansion  of  a  worker- function  is  the  executable  source  code  of  a 
high-level  language  such  as  FORTRAN.  Like  FORTRAN,  the  SFD  language 
has  its  own  syntax  and  semantics.  Graphic  symbols  comprise  the  SFD 
syntax,  and  the  control  constructs  dictate  its  semantics.  Figure  1.1.2 
shows  the  graphical  symbols  included  in  the  SFD  language. 
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The  Dialogue-Computational  node  denotes  a  supervisory-cell 
containing  both  Dialogue  and  Computational  nodes  in  its  SFD  expansion. 
The  dashed  Dialogue  and  Computational  nodes  represent  supervisory- 
cells  containing  only  dialogue  or  computational  functions  in  their 
respective  SFDs.  The  rectangular  node  represents  a  computational 
function  which  the  SFDs'  author  feels  is  too  insignificant  to  be 
included  in  a  separate  Computational  node.  The  hexagon  represents  a 
user  function  and  may  be  included  in  an  SFD  for  consistency  and  better 
requirements  representation.  Control  Flow  and  Data  Flow  are 
represented  by  solid  and  dotted  lines,  respectively.  Control 

conditionals  are  contained  within  <  >  symbols.  The  _  symbol 

represents  control  return  from  an  SFD  expansion  to  its  supervisory¬ 
cell.  Implied  conditionals,  to  be  explained  later,  are  o  symbols 
designating  control-line  intersections  having  special  semantic 
actions.  As  with  most  high-level  languages,  four  types  of  control 
constructs  are  defined.  These  are  show  in  Figures  1.1. 3-1. 1.6.  The 
remainder  of  this  report  presents  implementation  issues  concerning  BD 
development. 
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1.2  BD  Behavior  and  the  User's  Console 

The  user's  console  for  the  BD  consists  of  two  terminals:  a 
graphical  interaction  terminal  and  a  control-interaction  terminal. 
The  top  supervisory-cell  in  the  system  and  its  SFD  expansion  are  the 
items  displayed  by  the  BD  when  a  behavioral  demonstration  begins. 
This  is  displayed  on  the  graphical  interaction  terminal  (GG),  shown  in 
Figure  1.2.1,  with  the  cell  blinking.  The  control-interaction  terminal 
(TT)  displays  the  functional  description  of  the  cell,  data  passed  to 
and  from  the  cell,  and  the  control-flow  options.  Control  options  are 
selected  via  a  screen  directed,  touch-panel  keypad  as  illustrated  in 
Figure  1.2.2. 
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Control  advances  as  control  keys  are  pressed.  Each  node  in  the 
current  SFD  "executes"  and  control  returns  to  the  supervisory-cell. 

As  worker  nodes  for  a  system  are  expanded  (i.e.,  coded),  the 
Behavioral  Translator  may  be  used  to  execute  them  during  Behavioral 
Demonstration.  Finally,  to  conclude  system  development,  the  SFD 
Compiler  is  used  to  compile  and  link  SFD  modules  for  structured  walk¬ 
throughs  of  completed  sections  of  a  system. 


1.3  An  Example  BD 


In  order  to  illustrate  the  functions  of  the  BD  using  the  SFD 


language  described  in  Section  1.1  we  will  use  the  following 
hypothetical,  interactive  airline-reservation  system  as  an  example. 
This  example  also  appears  in  (J0HND82a)  and  ( YUNTT83 ]  and  is  repeated 
here  with  permission. 


1.3.1  Requirements  Specification 


PERFORM-AIRLINE-RESERVATION:  Manage  airline  reservation  activities  to 

serve  the  airline  users. 

REQUIREMENTS : 

1.  The  system  must  check  the  agent-id  everytime  a  person  logs  on  and 
adjust  agent- computer  communication  according  to  the  agent's 
expertise  level  (e.g.,  novice  or  expert). 

2.  The  system  must  perform  the  following  functions,  each  of  which 
can  be  invoked  independently  by  a  terminal  function  button. 

a.  Reservation 

b.  Get-payment 

c.  Cancel-reservation 

d.  Show-user' s-reservation-status 

3.  The  system  has  two  major  logical  record  structures.  These  records 


are  shown  in  Figure  1.3.1. 
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In  the  following,  the  requirements  specification  for  "GET- 
AGENT-  ID"  of  Figure  1.3.2  will  be  given. 


GET-AGENT-ID:  Gets  a  correct  identification  from  the  agent  when  the 

agent  logs  on. 

REQUIREMENTS: 

1.  The  system  must  have  a  list  of  valid  agent-id's  stored.  Figure 
1.3.3  expands  the  SFD  for  GET- AGENT- ID. 
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Normally,  all  control  and  data  lines  on  an  SFD  are  administered 
by  the  supervisory- function  with  one  exception:  "Communication  with 
the  data  bases  is  done  within  the  logic  of  a  supervised  computational 
function."  A  supervisory- function  only  invokes  a  supervised- function 
to  do  the  job.  For  instance,  in  Figure  1.3.3,  the  data  flow  of  GET- 
AGENT- ID  is  shown  by  a  double-line.  The  double-line  indicates  that 
this  flow  will  actually  happen  within  the  logic  of  CHECK- AGENT- ID .  It 


is  cited  on  the  SFD  to  show  the  existence  of  the  file. 

In  a  real  application-system  requirements  specification,  each 
of  the  other  supervisory-functions  would  be  further  refined,  providing 
that  this  information  was  available.  For  brevity  in  our  example,  we 
will  assume  that  the  remaining  specifications  are  still  quite 
abstract. 


1.3.2  BD  Operation 

Once  a  user  invokes  the  BD,  the  GG  displays  a  window  into  an 
SFD  structure  while  the  TT  expands  the  functional  description,  data 
descriptors,  and  control  alternatives  for  the  blinking  node.  Control 
selections  are  accepted  from  the  TT  video  touch-panel,  and  control 
advances  to  the  selected  node.  Figures  1.3. 4-1. 3. 9  illustrate  these 
advances  in  our  airline  example.  Figure  1.3.8  shows  how  selection 
control  is  represented,  and  Figure  1.3.9  depicts  iterative  control- 
flow. 

Although  our  example  only  illustrates  sequence,  choice,  and 
iteration,  the  BD  can  "execute"  complex  conditionals  and  recursion 
with  only  minor  modifications  to  the  SFD  "program."  In  Chapter  3  we 
shall  detail  the  representation  for  each  of  the  control  constructs. 
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2.0  DESIGN  ISSUES 

In  Section  1.3  we  gave  an  example  illustrating  how  the  BD 
operates.  Here  we  present  in  detail  all  of  the  functions  that  the  BD 
will  include  and  refine  the  SFD  language  and  BD  database  design. 


2.1  BD  Formal  Requirements  Specification 

The  BD  will: 

1.  Demonstrate  the  flow  of  data  and  control  in  systems; 

2.  Provide  a  communication  forum  for  design  teams  during 
the  development  process; 

3.  Serve  to  manage  progress  on  each  component  of  a  system; 
and 

4.  Enforce  the  SBSDM. 

To  demonstrate  the  flow  of  data  and  control  in  systems,  we  will 
use  the  SFD  language  with  more  precise  syntactic  specifications.  The 
SFD  language  syntax  should  visually  reflect  the  function  and  "state" 
of  each  component  in  a  system. 

As  users  of  the  BD  discover  requirement  inconsistencies  and 
needs  for  requirement  modifications,  the  BD  provides  an  opportunity 
for  those  users  to  document  their  observations. 

During  the  development  of  an  application  system,  programmers 
and  dialogue  authors  are  working  in  parallel  expanding  worker- 
functions.  Since  this  is  a  temporal  process,  some  facility  must  be 
provided  to  keep  track  of  the  progress  on  each  worker- function.  The 
BD  can  serve  not  only  to  verify  and  maintain  requirements,  but  also  to 
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continually  inform  users  of  system  progress  during  behavioral 
demonstration . 

The  designs  of  the  SFD  language  and  BD  enforce  the  methodology 
in  which  they  are  embedded. 

2.2  Graphical  Support  Environment 

The  BD  requires  a  supporting  graphical  editor  for  the  creation 
and  modification  of  SFD  "programs."  This  editor  provides  all  the 
features  in  an  SFD  structure  and  stores  these  structures  in  a 
transaction  database.  SFD  structures  will  include  the  following: 

-  Graphical  representation  of  supervisor-cells  and  their 
corresponding  SFD  expansions; 

-  Functional  descriptions  for  each  functional  component; 

-  Progress  reports  for  all  functional  components; 

-  Notes  and  comments  for  each  functional  component;  and 

-  Control  structure  linkage  descriptors  and  data  descriptors. 


2.2.1  SFD  Graphical  Standards 

Since  SFDs  pictorially  represent  function  as  well  as  structure, 
SFD  nodes  will  have  color,  size,  and  shape  standards.  Those  standards 
are  grouped  by  function  in  the  following  paragraphs. 
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CONTROL  STRUCTURES: 

In  the  SFD  language,  lines  represent  flow  of  control.  There  are 
three  types  of  control  flow  lines: 

-Control  lines  not  labelled  by  data  or  conditionals  are 
represented  by  solid, white  lines. 

-Control  lines  containing  only  data  are  represented  by  dash-dot, 
white  lines.  ■ 

-Control  lines  labelled  with  conditionals  are  presented  as 
dotted,  white  lines. 

This  specification  implies  that  no  control  lines  exist  which  contain 
both  data  and  a  conditional.  Note  also  that  control  lines  may  be  arcs 
as  well  as  straight  lines. 

The  two  remaining  control  constructs:  the  implied 
conditionals  and  the  return  branches  are  white  o  symbols 
and  red  symbols,  respectively. 


DATA  FLOW  STRUCTURES: 

Data  Flow  is  represented  by  white,  dotted  lines  or  arcs. 

All  lines  contain  arrow  heads  that  indicate  the  direction  of  both  data 
flow  and  control  flow. 
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D-C  NODE  STANDARDS: 

D-C  nodes  are  unshaded  in  the  inner  circle  and  unshaded  on  the 
outer  square. 

D-Cs  are  blue  if  the  have  a  corresponding  SFD  expansion  and  red 
if  they  have  not  been  expanded. 

D-Cs  should  not  exceed  5  cm  in  diameter. 

COMPUTATIONAL  WORKERS: 

Computational-Worker  functions  are  cyan,  unshaded  squares  not 
exceeding  2.5  cm  across. 

COMPUTAT I ONAL  SUPERV I SORS : 

Computational  Supervisors  are  unshaded,  dashed-line,  cyan  squares 
not  exceeding  3.8  cm  across.  If  a  Supervisor's  SFD  has  not  been 
expanded,  then  it's  node  will  be  red. 

DIALOGUE  WORKER: 

Dialogue-Worker  nodes  are  yellow,  unshaded,  circles  not  exceeding 
2.5  cm  in  diameter. 


DIALOGUE  SUPERVISORS: 

Dialogue  Supervisors  are  yellow,  unshaded,  dashed-line  circles 
not  exceeding  3.8  cm  in  diameter.  If  the  Supervisor  has  no  SFD 
expansion,  then  the  node  will  be  red. 
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USER  FUNCTIONS: 

User  Functions  are  represented  by  green,  shaded,  solid-line 
hexagons  not  exceeding  5  cm  across. 


COMPUTATIONAL  EXPANSIONS: 

Computational-Expansion  nodes  are  white,  shaded,  rectangles 
without  size  limitations.  The  explicit  code  expansion  will  be 
written  in  black  text. 


CONDITIONALS: 

Conditionals  label  control  lines  and  are  green  text  contained 
within  red  <  >  symbols.  The  <  >  symbols  are  optional. 


DATA  DESCRIPTORS: 

Data  Descriptors  are  magenta  text  that  label  Data  Flow  or  Control 
Flow  lines. 


2.2.2  Textual  Standards 

Standards  for  the  text  contained  in  the  functional 
descriptions,  progress  reports,  and  notes  made  by  the  users  are 
provided  in  the  following  paragraphs. 
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FUNCTIONAL  DESCRIPTIONS: 

Functional  Descriptions  of  system  components  contain  the 
following  information: 

-  The  description  of  the  function  this  component  will  carry 
out; 

-  The  data  passed  to  and  from  this  component;  and 

-  A  procedural  specification  containing  implementation  details, 
as  they  become  available. 

Figure  2.2.1  The  format  for  Functional  Descriptions. 
i  W> ;  V  ^  W  i  1  j  i  w  !  :r!-3  ».• 

A  brief  description  of  what  the  node 
does  goes  here. 

Requirements: 

Specif  icat  ions  that  the  node  is  to  r-'.eet . 


L?3T*'3  i  Description  of  the  data  used* 
( ed .  Nares I  char ( 5 )  i Jonn  J > 


PROGRESS  REPORTS: 

Progress  Reports  contain  the  following  information: 

-  The  date  the  expansion  for  this  node  was  complete; 

-  The  names  of  the  persons  responsible  for  this  node's 
expansion  (i.e.,  the  Task  Group  for  this  node);  and 

-  A  status  report  expounding  on  the  current  progress  and/or 
problems  which  are  impeding  progress. 


ivivy-v-  v*' >< '.*•  >v*  h 
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Figure  2.2.2  The  format  for  Progress  Reports. 


USER  NOTES: 

User  Notes  contain  the  following  information: 

-  The  date  the  notes  were  made  or  become  effective; 

-  The  priority  of  the  message  (Will  it  critically  affect 
progress?);  and 

-  A  section  for  notes  which  will  be  distributed  to  the 
"mailboxes"  of  the  Task  Group  members  for  this  node  based  cn 
the  date  and  priority  fields. 


V*  V  V 
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Figure  2.2.3  The  format  for  User  Notes. 


User  Notes  Forget 

Crest :sp  Data  Py*  L  C  ;*  L  ^  tj  Message  Priority 


N O  v  as  User-  N'cles. . .  Dialogue  4:t'v:r'&  oo.T.nei'ita  for  a  dIelocjua-:';uu'e) 


'j 
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2.3  Conceptual  Data  Model 

A  key  issue  in  the  design  of  the  BD  is  the  design  of  a  database 
representation  for  both  the  graphical  and  textual  content  of  SFD 
nodes.  Listed  below  are  the  entities  and  attributes  with  which  we  are 
concerned. 


2.3.1  Node  Attributes 


■  s 


cl 


Node_Name : 

Each  node  in  an  SFD  expansion  will  have  a  uniquely  identifying 
name.  This  name  will  be  an  abstract  of  the  functional 


a 

y 


description  of  the  node  and  will  serve  to  label  the  node.  It  also 
is  the  relation's  primary  key. 
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Node_Type : 

All  nodes  will  be  a  member  of 
Dialogue-Computational 
Computational-Worker 
Dialogue-Worker 
Computational-Expansion 


the  following  set  of  node  types: 
Computational-Worker 
Computational- Supervisor 
Dialogue- Supervisor 
User-Function-Module . 


Node_Compo  s i t i on : 

Each  node  has  a  graphical  representation  which  may  include 
related  graphical  entities  such  as  ^  and  o.  A  node's  composition 
descriptor  is  a  pointer  to  a  linked  chain  of  object  relations 
describing  the  graphical  composition  of  a  node  before  the  node  is 
expanded . 

Node_Expansion: 

Each  node  has  a  pointer  to  a  linked  chain  of  object  relations 
describing  its  SFD's  graphical  representation,  control  flow,  and 
data  flow. 


Node_Cont ro l_Entry : 

Each  node  has  a  pointer  to  the  first  object  relation  in  the 
Node_Expansion  chain  which  represents  the  first  function  to  be 
executed  when  the  supervisory-function  is  called. 

Node_Function : 

Each  node  has  a  corresponding  functional  description  written  by 
an  SFD  author  (i.e..  Project  manager  or  Systems  Analyst). 
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Node_Progress : 

Each  node  has  a  corresponding  progress  report  to  keep  the  system 
designers  informed  of  system  progress. 

Node_Notes: 

During  behavioral  demonstration,  the  user  has  the  opportunity  to 
make  notes  which  would  later  be  read  by  the  node's  author(s). 


2.3.2  Oblect  Attributes 
Ob j ect_Name : 

Objects  of  the  executable  type  (e.g.,  Computational-Worker)  have 
unique  object  names  which  serve  as  primary  keys  in  the  object 
relations.  These  names  correspond  to  the  Node_names  in  the  Node 
relations.  Text  for  objects  of  type  COND,  TEXT,  and  DATA  will 
appear  in  this  tuple  and  can  be  thought  of  as  an  attribute  of  the 
object  that  functions  the  same  as  the  object's  name. 

Ob j  ect_Type : 

Object_Type  describes  the  graphical  entity  that  an  object 
represents. 

Object_Color: 

Each  object  has  a  color  descriptor. 

Ob j  ec t_Shading : 

Objects  may  be  shaded,  unshaded,  or  system-defined  composites. 
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Ob j  ect_location : 

All  objects  can  be  positioned  by  knowing  two  absolute  coordinates 
relative  to  the  absolute  origin  on  the  screen. 

Object_Link 

Each  object  may  be  composed  of  other  objects  and/or  SFD  nodes. 
This  attribute  links  objects  in  the  same  object  chain. 

Object_Successor : 

Objects  of  type  EDGE  represent  control  lines  connecting  two 
nodes.  These  objects  have  a  successor  attributes  whose  tuple 
values  are  pointers  to  the  node  to  be  executed  once  this  EDGE  has 
been  traversed. 


2.4  Definition  of  Formal  Relations 

The  conceptual  data  model  is  formalized  after  the  CODASYL 
relational  database,  and  presented  in  Figure  2.4.1  as  that  model  is 
implemented  under  DMS.  Clearly,  during  implementation  some  new 
attributes  were  defined.  We  introduced  these  new  relations  in  order 
to  satisfy  certain  hardware  characteristics  of  the  GG  device. 

HOPE  RELATION _ 

.  .vans  :?«M  |  Composition  i  Expansion  i  Control  i  Function  j  Frc^rass  .  jfcias  .  Claar  . 
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3.0  BD  EXECUTION  ENVIRONMENT 

The  BD  execution  environment  contains  three  support  subsystems: 
the  SFD  language  editor,  the  BD  database  manager,  and  the  BD  proper. 
The  SFD  language  editor  and  the  BD  database  manager  were  discussed 
earlier;  in  this  Section,  the  BD  proper  and  its  relationship  to  the  BD 
database  are  examined. 


3.1  BD:  A  Finite-State  Automata 

The  BD  is  a  push-down  automata  operating  on  relations  contained 
in  the  transaction  database.  As  each  SFD  node  is  retrieved  from  the 
BD  database,  the  BD  moves  from  state  to  state  and  node  expansion  to 
node  expansion.  A  stack  becomes  useful  when  the  BD  retrieves  a 
supervisory-cell  that  has  an  SFD  expansion.  The  BD,  in  this  case,  must 
stack  the  current  window  of  the  supervisory- structure  shown  on  the  GG 
and  the  current  node  position  within  the  SFD  now  executing.  In  this 
way,  the  BD  will  be  able  to  "return"  from  a  lower-level  SFD  expansion 
to  its  supervisory-function  and  continue  behavioral  demonstration.  In 
at  least  one  situation,  the  handling  of  implied  conditionals,  semantic 
actions  are  also  placed  on  the  stack;  hence,  the  BD  could  be  viewed  as 
an  augmented  transition  network. 
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Figure  3.1.1  shows  the  stacking  action  of  the  BD. 
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BD 


During  behavioral  demonstration,  the  BD  dynamically  binds  with 
each  pair  of  edge-connected  SFD  nodes  a  control  and  data-flow 
structure.  This  structure  then  governs  how  the  BD  displays  on  the  TT 
the  control-path  alternatives,  the  functional  descriptions,  the  data 
descriptors,  and  the  command- level  alternatives.  The  BD  treats  each 
SFD  entry  as  a  token  of  the  graphical-requirements  language.  The 
refined  SFD  syntax  governs  how  each  SFD  node  may  be  interpreted  and 
later  expanded. 

For  illustration,  consider  our  airline  example  discussed  in 
Section  1.3.  The  BD  first  retrieves  the  node  relation  with 
Node_Name  =  ' PERFORM-AIRLINE-RESERVATION. '  A  typical  relation 

retrieval  might  return  the  tuples  shown  in  Figure  3.1.2.  The  BD  then 
expands  the  node's  graphical  composition  and  expansion  by  following 
Node_Composition  and  Node  Expansion  to  their  respective  Object  chains 
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and  converting  the  tuple  values  retrieved  from  these  Object  relations 
into  subroutine  calls  for  graphic  display.  The  BD  displays  the 
functional  description  for  the  current  cell  by  simply  displaying  the 
value  contained  in  the  Node_Function  tuple.  It  then  follows 
Node_Control_Entry  to  the  first  Object  relation  on  the  control  path. 
Based  on  the  tuple  values  obtained  from  this  object  relation  the  BD 
redraws  the  first  node  blinking. 


'' *•*« TYPICAL  RELATE  RETRIEVAL 

The  current  state-of-af fairs  is  placed  on  the  stack  and 
expansion  for  the  blinking  node  continues  similarly.  After  control 
returns  to  the  supervisory-cell  (GET-AGENT-ID  is  popped  off  the  stack, 
the  object  relations  comprising  the  cell  are  searched  for  objects  of 
type  DATA,  COND,  and  EDGE.  DATA  objects  are  used  for  displaying 
parameters  and  COND  objects  are  bound  with  EDGE  object 
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Object_Successors.  The  BD  generates  keys  on  the  TT  to  correspond  with 
the  COND  labels  (discussed  in  Section  3.3.4)  and  binds  with  the  input 
of  each  key  the  object  pointer  contained  in  the  Object_Successor  of 
the  bound  EDGE  object. 

After  continuing  in  this  process,  the  BD  will  expand  the  last 
node  in  the  SFD  for  PERFORM- AIRLINE- RESERVATION  and  return  to  the 
PERFORM-AIRLINE-RESERVATION  node,  concluding  behavioral  demonstration. 


The  following  algorithim  describes  how  the  BD  windows  SFDs: 

INPUT  :  Object  relation  to  execute. 

OUTPUT:  Object's  SFD  expansion  window. 

Save  Object_Location  coordinates 

Extract  Node  relation  where  Node_Name  =  Object  Name 
Extract  Object  relation  pointed  to  by  Node_Composition 
Take  the  difference  between  the  saved  Object_Location 
coordinates  and  the  Object_Location  coordinates 
specified  by  Node_Composition 
While  the  coordinates  are  different  do 

Translate  the  current  Node_Expansion  object  by 
object  by  an  offset 

Add  offset  to  the  -saved  Object_Location  coordinates 
and  re save 
End  While 

Expand  Object  chain  specified  by  Node_Expansion 
Blink  object  specified  by  Node_Control_Entry 
Go  to  Control  Mode 

The  above  algorithim  illustrates  the  control  flow  for  SFD 
windowing  but  fails  to  explain  how  the  objects  are  actually  drawn.  We 
will  not  concern  ourselves  with  this  issue  since  it  is  hardware 
dependent.  In  a  nutshell,  the  BD  converts  object  tuple  values  into 
parameters  for  simple  graphic  routines  which  draw  basic  objects. 
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3.3  Textual  Expansion 


The  following  algorithm  describes  how  the  BD  dynamically  binds 
conditionals  to  control  paths  and  generates  control-option  labels  for 
labelling  touch-keys  on  the  TT: 


INPUT  :  Object  relation  to  execute. 

OUTPUT:  New  path  for  control  [user's  choice]. 
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If  Object_Type  =  IMPL  then 

Next_Object  =  Object_on_Stack 
Else 

Indexl  =  1 
Index2  =  1 

Control_key( 1 )  =  'NEXT  NODE' 

While  Object_Type  is  not  executable  do 

Extract  next  Object  relation  on  Object  chain 
If  Object_Type  =  COND  then 

Control_key( Indexl )  =  Object_Name 
Indexl  =  Indexl  +  1 
End  If 

If  Object_Type  =  EDGE  then 

Control_path( Index2 )  =  ObjectSuccessor 
Index2  =  Index2  +  1 
End  If 
End  While 

Display  Control_keys  and  receive  input  in  KEY 
Index  =  Input_key(KEY) 

Next_Object  =  Control_path( Index) 

End  If 

Since  the  other  textual-expansion  functions  the  BD  performs  are 
fairly  straight-forward  their  algorithms  are  not  included. 


PAGE  41 


3.3.1  TDB  Description 

[HARTH83]  describes  the  Transaction  Data  Base  (TDB)  as  a 
database  resident  in  primary  memory  that  manages  screens  for 
application  programs.  In  a  later  version  of  DMS  there  will  be  a 
secondary  storage  database,  the  Dialogue  Data  Base  (DDB),  which  will 
contain  all  screens  for  applications.  The  TDB  contains  the  following 
predefined  relations  [HARTH83]:  Screen,  Group,  and  Object.  Each  Screen 
is  composed  of  Groups  of  Objects,  where  Objects  in  the  same  group  are 
stored  in  a  dequeue  that  links  Object  relations.  These  three  relations 
can  easily  represent  the  SFD  Node  and  Object  relations  thus 
maintaining  consistency  within  the  DMS  environment.  For  more 
information  concerning  the  TDB  or  SFD  relations  as  implemented  on  the 
TDB  we  refer  our  readers  to  [HARTH83]. 


3.3.2  BD  I/O  Support 

DMS  currently  supports  two  device  drivers  as  described  in 
[EHRR82a].  Following  the  SBSDM  tradition,  these  drivers  are 
intelligent  device-drivers  providing  high-level  interactive  dialogue 
services  for  both  the  TT  and  GG  devices.  PAD,  a  service  that  draws  a 
touch-panel  on  the  screen,  is  an  example  common  to  both  drivers; 
whereas,  CIRCLE,  a  service  that  draws  a  circle  on  the  screen,  is  an 
example  included  only  in  the  GG  device-driver.  The  BD  uses  the  TT  and 
GG  drivers  to  generate  the  dialogue  for  .ual  and  graphical 

expansion,  respectively. 

During  execution,  the  BD  retrieves  tuple-relations  from  the 
TDB,  translates  the  tuple  values  into  service  calls  to  the  TT  and  GG 
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The  first  Object  relation  translates  into  the  following  FORTRAN  calls 
to  the  GG  device-driver: 

Call  Box  ('gg' ,X2, Y2,X1,Y1, ' keep' //line_mode//write_mode//color// 
shading//b linking) 

Call  Circle 

( 'gg' ,X2/2,X1,Y1, ' keep ' //line_mode//write_mode//color// 
shading//blinking) 

For  more  information  on  the  device-drivers  see  [EHRR82b]. 


B. 


The  BD  next  expands  the  function  description  for  PERFORM- 
AIRLINE-RESERVATION  on  the  TT  by  simply  printing  the  value  of  the 
Node_Function  tuple.  It  next  clears  the  GG  screen  based  on  the 
value  of  Node_Clear  and  expands  the  SFD  expansion  by  translating 
the  Object  chain  pointed  to  by  the  value  of  Node_Expansion  into 
GG  device-driver  calls.  Once  the  expansion  has  been  drawn,  the 
BD  stacks  the  current  node  and  object  values  and  passes  control 
to  the  object  pointed  to  by  Node_Control_Entry . 

Tuple  translation  continues  similarly  until  the  tuple 
value  for  Node_Control_Entry  =  nil  or  control  passes  to  an  object 
of  type  RETN.  At  this  point  the  BD  "pops”  the  stack  values  and 
continues  execution. 
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3.3.4  BD  Command  Alternatives 

Previous  Sections  have  alluded  to  the  Progress  Reports  and 
User  Notes  but  have  not  discussed  how  BD  users  access  and  use 
these  entities.  Figures  1.3.4  -  1.3.9  show  various  command 

alternatives  as  they  appear  on  the  TT  touch-panel  for  our  airline 
example.  These  figures  illustrate  the  three  command  alternatives 
which  are  detailed  here: 

CONTINUE  -  continues  sequential  execution.  This  command  is 
used  for  stepping  sequentially  through  TT 
displays. 

PROGRESS  -  displays  the  node's  Progress  Report  in  the 
functional-description  text  box. 

NOTES  -  places  the  BD  into  edit-mode  so  that  the  user  may 
enter  notes.  After  these  notes  have  been 
entered,  they  will  be  routed  to  the  mail  files  of 
the  persons  responsible  for  the  node's  expansion. 

In  earlier  Sections  we  mentioned  the  implied  conditional.  This 
is  an  implied  state  and  command  alternative  included  in  the  SFD 
language  syntax.  Consider  the  SFD  and  its  corresponding  code  shown  in 
Figure  3.3.3. 
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LA5£L  #i:  IF  CONDITION  #1  THEN 


C^L  8 

GOTO  ‘.fiSti.  <•£ 

END  IF 

IF  CONDITION  rE  THEN 
Out  C 
GOTO  LAbcl 


;  ccraiiior.  rr 


LHuL  J 

IF  CONDITION  *3  THEN 
COTO  LABEL  #i 
run  re 

IF  CONDITION  #4  THCM 
9:n  iom 
curs  re 


t; 


When  control  has  passed  through  node  A  and  the  user  has  chosen 
to  go  to  node  C,  then  after  leaving  node  D  control  passes  to  node  C. 
This  causes  node  A  to  be  expanded  only  once. 


3.3.5  Problems  and  Solutions 

Currently,  the  BD  places  a  restriction  on  SFD  structures:  only  fifteen 
edges  are  allowed  on  nodes.  The  TT  touch-panel  having  only  eighteen 
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keys  makes  this  restriction.  Clearly,  this  could  become  a  problem  for 
P  an  application-system  design  for  which  there  are  large  "Case" 

structures.  A  solution  to  this  problem,  to  be  included  in  a  future 
version  of  the  BD,  would  be  to  add  a  service  to  both  the  TT  and  GG 
Bl  drivers  which  can  maintain  a  touch-keyboard  similar  to  the  one 

depicted  in  Figure  3.3.4.  During  execution,  the  BD  would  adapt 
s*  keyboards  to  the  application  required. 


>„ 
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4.0  BEHAVIORAL  DEMONSTRATION  OF  THE  AIRLINE  EXAMPLE 

Figures  4.1.1  -  4.3.3  depict  a  terminal  session  with  the  BD. 
The  airline  example  is  used  again.  Data  expansion  is  excluded  for 
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simplicity,  but  for  completeness  it  is  illustrated  in  Figure  4.2.5 


J 13353  emar'  a oc*  N003: 

A*r  line.  - 
/^eser‘vtx.4''  on. 


After  the  user  enters  the  root  node,  in  this  case  PERFORM- AIRLINE - 
RESERVATION,  the  database  is  searched  and  the  SFD  for  the  root  node 
retrieved. 
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| Manage  airline  reservation  activity; 
i io  serve  the  airline  users. 
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The  requirements  specifications  for  the  root  node  are  displayed,  and 
the  user  selects  a  command  option.  In  this  case  CONTINUE  is  selected. 


The  SFD  for  the  current  node  is  expanded  and  demonstration  continues 
with  the  entry  node  in  the  SFD  expansion. 
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User  selects  CONTINUE. 
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The  SFD  for  GET-AGENT-ID  is  expanded  and  demonstration  continues  with 
ASK- FOR- AGENT- ID. 
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User  presses  CONTINUE. 


;  lAsks  a  parson  ic  aniar  his/har  ie.  i 


i 

lunnri  i 


Since  ASK- FOR- AGENT- ID  is  a  worker  node  (Dialogue)  the  user  is  given 
the  option  to  continue  sequentially  through  the  SFD  to  the  next  node. 


User  selects  NEXT  NODE 
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Demonstration  continues  until  control  reaches  the  decision  point  where 
valid-flag  requires  a  value.  In  Figure  4.2.2  the  user  is  given  the 
choice  of  two  control  paths.  User  selects  Valid-FlagoOK. 
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Control  continues  in  an  iterative  loop  until  the  user  selects  Valid- 
Flag=OK  in  Figure  4.2.6,  then  demonstration  resumes  with  the 
supervisory- structure  that  supervises  GET-AGENT- ID,  shown  in  Figure 
4.2.7. 
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Demonstration  continues 
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5.0  FUTURE  WORK 

In  Section  1.0  the  BD  was  presented  as  one  of  three  similar  and 
related  design- tools  to  be  integrated  into  DMS .  Neither  the  Behavioral 
Translator,  nor  the  SFD  Compiler  have  as  yet  been  discussed.  Those 
design  tools  represent  areas  for  future  work. 

The  SFD  Compiler  will  produce  the  code  for  a  system,  or  subsets 
of  a  system,  after  the  supervisory- structure  for  the  system,  or 
subset,  has  been  completed.  The  code  produced  will  be  written  in 
Fortran,  Pascal,  or  some  other  high-level  programming  language. 
Clearly,  since  most  of  the  complicated  control  constructs  will  be 
coded  automatically  by  the  SFD  compiler,  productivity  on  a  system 
design  using  the  SBSDM  will  be  greatly  increased. 

The  SFD  Translator  allows  designers  of  systems  to  execute  any 
completed  portion  of  a  system  during  any  phase.  By  checking  the 
progress  report  on  each  node  the  SFD  Translator  determines  if  the  node 
has  been  completed.  Completed  computational  nodes  are  linked  and  the 
data  necessary  for  execution  binded.  A  separate  process  is  allocated 
to  "run"  the  completed  nodes  and  interprocess  "windows"  are  used  to 
retrieve  output  data.  For  completed  dialogue  nodes  the  SFD  Translator 
calls  the  "dialogue  executer"  to  perform  a  dialogue- transaction.  See 
[JOHND82a]  for  a  description  of  dialogue-transactions  and  the 
"dialogue  executer." 
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